Known image processing systems have performed image processing using either a push model or a pull model. As shown in FIG. 1, in a push model all source data is pushed from the source (also referred to as an “input” (e.g., the original source image)) to the sink (also referred to as the output or a resulting processed image). In such a configuration, the image data is ‘pushed’ through the image chain from the source(s) to the sink by: (a) fetching the image data (usually from disk) and storing the image data in an internal memory buffer; (2) applying each of the image processing operations sequentially (from the source to the sink); and (3) storing the resultant image data to disk and/or display on a monitor.
However, known push models have known limitations which can detract from their usefulness under certain conditions. For example, if an image to be processed is very large as compared to the available RAM, then intermediate results may need to be written to disk, thus incurring performance (time) and hard drive usage penalties. Similarly, when image data is sequentially processed in its entirety from source to sink, it may be difficult to concurrently process (thread) smaller chunks in order to optimize performance (time). Likewise, the push model may not work well for interactive applications.
INTEL™ Threading Building Blocks (TBB) is a toolkit for writing parallel programs. TBB contains a pipelining capability, which is a common parallel pattern that mimics a traditional manufacturing assembly line. Using such pipelining, data has traditionally flowed from the source to the sink. TBB also only supports linear pipelines (no branching is allowed in the chain).
Unlike the push model, the demand-pull model, as shown in FIG. 2, processes image data in response to a request for a smaller image ‘chunk’ known as a tile and is, therefore, more complicated than the push model. The demand for a tile of image data moves from the sink up through the operators (i.e., the operations to be performed on the image) and then finally to the source. The source retrieves the requested tile of image data into memory, possibly from a disk file. The tile then flows down from the source to the sink, passing through each of the operators where the image data is processed. While the pull model may reduce the overall memory footprint by using smaller chunks of the image, called tiles, which can sometimes be concurrently processed and/or cached, the pull model also comes with additional complexities and/or disadvantages. For example, software for managing the concurrency (multiple threads) of work being performed often is custom written which adds to the development cost and detracts from the actual task of writing the image processing framework.